---
display_title: "Choosing a CMS in 2025: A Guide for Technical Teams"
meta_title: "Choosing a CMS: Sanity vs Payload vs GitHub vs Keystatic"
meta_description: "A deep guide to choosing a CMS in 2025. Compare Git-based CMS, headless CMS like Sanity and Payload, Nextra-style frameworks, GitBook, and when you shouldn’t use a CMS at all."
author: "John Jeong"
created: "2025-11-28"
published: true
---

# Choosing a CMS in 2025: A Guide for Technical Teams

If you’re building a blog, docs, or a knowledge base in 2025, the options are… overwhelming.

Sanity or Payload?  
Nextra or GitBook?  
Git-based CMS like Keystatic?  
Or just raw MDX in GitHub with zero CMS at all?

We went through the same decision for Hyprnote.  
This post is my attempt to **map the territory** so you don’t have to burn as many cycles.

I’m not going to tell you “X is the best CMS.”  
I’ll show you **what each category is good at**, what it quietly locks you into, and when you probably don’t need a CMS at all.

**This is Part 3 of our publishing series.**

1. [Why We Write Our Blog in an IDE](/blog/using-ide-for-writing)
2. [Why Our CMS Is GitHub](/blog/why-our-cms-is-github)
3. [Choosing a CMS in 2025](/blog/choosing-a-cms) (You are here)
4. [Don't Use a CMS Until You Absolutely Need One](/blog/dont-use-a-cms)
5. [Docs Edition: What to Use for Developer Documentation](/blog/developer-documentation-tools)
6. [How We Built Hyprnote's Publishing Stack](/blog/hyprnote-publishing-stack)

## Step 0: Decide What Problem You’re Actually Solving

“Which CMS should we use?” is the wrong first question.

Better questions:

1. **Who is writing most of the content?**
   - engineers only  
   - mixed team (engineers + PMs + marketing)  
   - non-technical people only  

2. **What are you publishing?**
   - technical blog  
   - product docs / API reference  
   - internal knowledge base  
   - marketing pages / landing pages  

3. **How often does content structure change?**
   - almost never (simple posts, titles, tags)  
   - sometimes (new fields, types, locales)  
   - constantly (complex content models, multiple channels)  

4. **How long should your content survive?**
   - 6 months?  
   - 2–3 years?  
   - 10+ years and multiple stack rewrites?

Once you answer these, the CMS choice mostly falls out.

## The Four Big Buckets of CMS Options

Let’s define the buckets first:

1. **No CMS, just Git + MDX**  
2. **Git-based CMS (visual UI on top of your repo)**  
3. **Headless CMS (API-first like Sanity, Payload)**  
4. **Hosted doc/knowledge platforms (GitBook, Notion, etc.)**

We’ll walk through each, then I’ll give you a “when to pick which” section.

## 1. No CMS: Just Git + MDX (What We Use)

This is what we do at Hyprnote:

- content lives as `.mdx` files in the repo  
- we write in Zed / Cursor / VS Code  
- GitHub is the CMS  
- PRs are drafts, merges are publish  
- CI handles link checking, OG generation, etc.

Pros:

- maximum **portability** (plain files last decades)  
- works perfectly with modern frameworks (Next.js, TanStack Start, Astro) via [MDX support](https://nextjs.org/docs/pages/guides/mdx)  
- diffable, reviewable, scriptable  
- no vendor lock-in, no schema migrations  
- ideal if your writers are engineers

Cons:

- non-technical teammates need training or another surface  
- no drag-and-drop media UI out of the box  
- no built-in content dashboard, workflows, or roles

If your team is very technical and you’re early-stage, this is almost always the correct default. You can always add a Git-based or headless CMS later without throwing anything away.

## 2. Git-Based CMS: “UI for Your Repo” (Keystatic & Friends)

Git-based CMS tools give you a **visual editor that talks directly to your Git repo**. Your content is still Markdown/MDX/JSON/YAML in the repository, but non-technical people get a web UI.

**[Keystatic](https://keystatic.com/)** is a good example of the modern version of this: it makes Markdown, JSON, and YAML content in your codebase editable via a browser UI, and syncs changes directly to GitHub or the local file system, without introducing a separate database.  

Other players in this space include TinaCMS, Decap, etc., which a lot of devs compare as “Git-based CMS for React/Next.” ["Git-based CMS for React/Next"](https://dev.to/linkb15/top-5-git-based-cms-comparison-as-of-april-2024-4k1e)

Pros:

- fits the **“content as code”** philosophy
- you keep all the benefits of Git (history, branches, PRs)  
- non-engineers get a UI to edit content safely  
- still portable (files in Git), no proprietary content lake  
- good fit for Next.js / Remix / Astro setups

Cons:

- another admin app to host/configure  
- the UI still has limits vs raw MDX  
- you’re tied into their config models and upgrade cycle  
- not as “enterprise omnichannel” as big headless CMSs

When to use this:

> You like our Git + MDX approach, but you want PMs / designers / marketing to be able to tweak copy and metadata without opening an IDE.

---

## 3. Headless CMS: Sanity, Payload, and the Heavy Hitters

Headless CMS = content backend with APIs. Frontend is up to you.

You define schemas, models, relationships, and the CMS exposes content via REST/GraphQL/other APIs to web, mobile, native apps, signage, whatever. [REST/GraphQL/other APIs](https://www.sanity.io/headless-cms)  

### Sanity

Sanity is one of the big names here:

- it offers a composable “Content Cloud” with an open-source Studio built in React/TypeScript, highly customizable, and aimed at flexible content modeling. [Sanity](https://www.sanity.io/)  
- content is stored in their **Content Lake** as structured JSON, not HTML, so you can reuse it across multiple frontends. [Content Lake](https://pagepro.co/blog/what-is-sanity/)  
- it provides real-time collaboration, visual editing, and omnichannel delivery.

This is great when you have multiple frontends, lots of content types, and non-technical editors who need good UX.

### Payload

Payload is a dev-first, code-first headless CMS built with Node.js, TypeScript and React, positioning itself as a Next.js-native backend framework. [Payload](https://payloadcms.com/)  

- you configure everything in TypeScript  
- it’s open-source (MIT), self-hostable, and can double as a headless CMS, app framework, or digital asset management layer. [open-source](https://github.com/payloadcms/payload)  
- it fits naturally into a modern JS/TS stack with Next.js-based projects. [Next.js-based projects](https://payloadcms.com/docs/getting-started/what-is-payload)  

Pros of headless CMS:

- powerful **schema & content modeling**  
- omnichannel delivery (web, mobile, internal tools)  
- good editorial UIs, roles, workflows  
- often built-in localization, scheduling, etc. [localization, scheduling, etc.](https://www.sanity.io/headless-cms)  

Cons:

- more infra complexity (hosting, API auth, migrations)  
- content now lives in a **proprietary structure** (export is possible, but not as simple as copying MDX files)  
- your team must think in terms of “schemas” and “content models,” not just “posts”  

When to use this:

> You’re not just running a blog. You’re running a **content platform** with multiple surfaces, locales, and non-technical editors who need structured workflows.

---

## 4. Docs / Knowledge Platforms: GitBook, Notion & Co.

Sometimes you don’t need a CMS. You need a **docs product**.

### GitBook

GitBook positions itself as a documentation + knowledge base platform for technical teams, with a polished block-based editor, site customization options, and Git Sync that lets you connect to GitHub/GitLab for a docs-as-code workflow. [GitBook](https://gitbook.com/docs)  

It’s very good if you want:

- a hosted, beautiful docs site  
- search, navigation, versioning, and collaboration  
- optional Git synchronization for teams that still want Markdown in repos [Git synchronization](https://gitbook.com/docs/guides/docs-best-practices/documentation-structure-tips)  

Notion, Confluence, etc. live in the same general category (less dev-focused, more general knowledge management).

Pros:

- **fastest path** to a nice-looking docs/knowledge base  
- low setup cost, almost no infra  
- very friendly for non-tech stakeholders  
- often have built-in AI-assisted search/summary now [AI-assisted search/summary](https://www.gitbook.com/)  

Cons:

- content portability is limited (exports often messy)  
- integrating tightly into your product site can be harder  
- you’re living inside someone else’s product roadmap  

When to use this:

> You want a **docs site tomorrow**, UX matters more than control, and you don’t mind long-term platform dependency.

---

## Summary: The Four Buckets at a Glance

| Bucket | Best For | Pros | Cons | Examples |
|--------|----------|------|------|----------|
| **No CMS (Git + MDX)** | Technical teams, engineers writing content | Maximum portability, no vendor lock-in, diffable/reviewable, perfect IDE integration | No visual UI, non-technical users need training | Plain MDX in GitHub |
| **Git-Based CMS** | Mixed teams needing visual UI while keeping content in Git | Content-as-code benefits + visual editing, portable files, non-engineers can edit | Extra admin app to host, tied to their config models | Keystatic, TinaCMS, Decap |
| **Headless CMS** | Multi-channel content platforms with complex workflows | Powerful schema modeling, omnichannel delivery, great editorial UX, localization | Infrastructure complexity, proprietary content structure, migration cost | Sanity, Payload |
| **Docs Platforms** | Teams needing polished docs/KB sites fast | Fastest setup, beautiful out-of-box, low infra cost, non-tech friendly | Limited portability, harder product integration, platform dependency | GitBook, Notion, Confluence |

---

## 5. Special Case: Nextra & Friends (Frameworks, Not CMSs)

Tools like **Nextra** are not CMS platforms, but content-focused frameworks built on Next.js that make it easy to build docs/blog sites with Markdown/MDX and opinionated themes. [Nextra](https://nextra.site/docs)  

Think of Nextra as:

- prebuilt docs/blog UI (sidebar, nav, search glue)  
- MDX-first authoring  
- great for developer docs & personal blogs

You still choose how to manage content (just files, Git-based CMS, headless CMS feeding MDX remotely, etc.).

This is the category Hyprnote’s stack rhymes with: modern React/MDX front-end, but content-first in Git.

---

## A Simple Decision Matrix (So You Don’t Overthink It)

You can ignore everything above and just use this:

| Situation | Likely Best Choice |
|----------|--------------------|
| Small, technical team, mostly engineers writing | **Git + MDX, no CMS** |
| Technical team, but PMs/design/marketing need to edit copy | **Git-based CMS** (Keystatic/Tina/etc.) |
| Product needs content across web, app, marketing, multiple locales | **Headless CMS** (Sanity, Payload, etc.) |
| You just need a docs/KB site ASAP | **Docs platform** (GitBook, maybe Notion early) |
| You want fine control over UI + MDX, but not heavy infra | **Nextra or similar framework** on top of Git |

If you’re not sure, default to:

> **Git + MDX now.  
> Add a Git-based or headless CMS later _if_ reality forces you to.**

Most teams overestimate how much “CMS” they need for the first 2–3 years.

---

## Things People Don’t Talk About Enough

A few non-obvious things we learned while thinking about this for Hyprnote:

### 1. Lock-in doesn’t hurt until you’re tired and busy

Headless CMS and hosted doc platforms feel great in the first year. Export and migration problems show up **right when you least want to deal with them**: when the product is working and you’re stretched thin.

Plain files in Git are boring. Boring is good.

### 2. Editors become culture

If your team writes in Markdown/MDX in Git, your culture becomes:

- “open a PR”  
- “leave a comment”  
- “fix it in the repo”  

If your team writes in a SaaS editor, your culture becomes:

- “who has access?”  
- “which space is that in?”  
- “did the integration break again?”  

Neither is inherently “right,” but they lead to different organizations.

### 3. Your writers will change over time

Today your blog might be “founder + engineers.”  
In two years, it might be “devrel + marketing + product + support.”

Choosing a stack that can evolve from **IDE-only → Git-based CMS → headless CMS** with minimal rewriting is underrated.

Git + MDX is a good foundation for that.

---

## So… What Would I Use If I Were Starting Today?

If I were a technical founder starting a new product today:

- For **blog + marketing + simple docs**  
  → I’d start with **Next.js or TanStack Start + MDX + GitHub**, no CMS.  
- When non-engineers need to edit regularly  
  → I’d add a **Git-based CMS** like Keystatic on top. [Keystatic](https://keystatic.com/)  
- If I ever hit real omnichannel, multi-locale complexity  
  → I’d consider **Sanity or Payload** and accept the trade-offs. [Sanity or Payload](https://nextjstemplates.com/blog/headless-cms-nextjs)  
- For standalone internal knowledge bases  
  → I’d probably just use **GitBook** and not overthink it. [GitBook](https://gitbook.com/docs)  

That’s basically our philosophy behind Hyprnote’s own stack:  
start with the simplest thing that respects **developer workflows, portability, and long-term ownership.**

The tools will change.  
Your content shouldn’t have to.

---

**This is Part 3 of our publishing series.**

1. [Why We Write Our Blog in an IDE](/blog/using-ide-for-writing)
2. [Why Our CMS Is GitHub](/blog/why-our-cms-is-github)
3. [Choosing a CMS in 2025](/blog/choosing-a-cms) (You are here)
4. [Don't Use a CMS Until You Absolutely Need One](/blog/dont-use-a-cms)
5. [Docs Edition: What to Use for Developer Documentation](/blog/developer-documentation-tools)
6. [How We Built Hyprnote's Publishing Stack](/blog/hyprnote-publishing-stack)
